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I. REAL PARTY IN INTEREST 

The real party in interest is EMC Corporation, by virtue of assignments recorded at Reel 
014545 Frame 0931 and Reel 014880 Frame 0696. 
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II. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences. 
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III. STATUS OF THE CLAIMS 

Claims 1-53 have been presented for examination. 

Claims 1-28, 35-39, and 47-51 have been withdrawn from consideration. 

Claims 29-34, 40-46, 52, and 53 have been finally rejected, and are being appealed. 
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IV. STATUS OF AMENDMENTS 

No amendment was filed after the final rejection, although a Petition for Withdrawal of 
the Requirement for Restriction/Election was filed on Aug. 13, 2007. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

The appellants' invention of claim 29 is directed to a file server (21 in FIG. 1). The file 
server includes storage (29 in FIG. 1) containing a file system (54 in FIG. 2), and a processor (26 
in FIG. 1) for accessing the file system. The file system includes a production file, read-only 
snapshot copies of the production file, and at least one read-write snapshot copy of the 
production file. The production file and the snapshot copies of the production file are organized 
as a version set. The version set includes an inode (171 in FIG. 19) for the production file and an 
inode (172-176 in FIG. 19) for each snapshot copy of the production file, and a set of file blocks 
(177 in FIG. 19) including data blocks and indirect blocks that are shared among the production 
file and the snapshot copies of the production file. See, for example, appellants' FIG. 15, which 
shows inodes (131, 140) sharing data bocks (132, 134, 135, 138, 139) and indirect blocks (133, 
136, 137), and FIGS. 19 and 23 which show a version set including read-only snapshot version 
inodes (172, 173, 174) and read-write snapshot branch inodes (175, 176), and FIG. 24, which 
shows the creation of a read-only version of the production file, and FIG. 25, which shows the 
creation of a read-write branch off a read-only base version. (Appellants' specification, page 3 
line 21 to page 4 line 6, page 32 lines 5-22, page 40 line 1 1 to page 42 line 12, page 46 lines 12- 
21, page 50 line 3 to page 51 line 5.) 

The file server of appellants' claim 29 further includes the following "means plus 
function" as permitted by 35 U.S.C. 112, sixth paragraph., which are identified as follows 
together with their structure, material, or acts described in the specification as corresponding to 
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each such claimed function. None of the other elements of claim 29 are "means plus function" 
or "step plus function," and none of the other claims on appeal contain "means plus function" or 
"step plus function" as permitted by 35 U.S.C. 1 12, sixth paragraph. The appellants' "means for 
creating new read-only snapshot copies of the production file" of claim 29 is shown in 
appellants' FIG. 24, steps 221-227, as described in appellants' specification on page 50 lines 3- 
15. The appellants' "means for creating new read-write snapshot copies of the production file" 
of claim 29 is shown in appellants' FIG. 25, steps 231-237, as described in appellants' 
specification on page 50 line 16 to page 51 line 5. The appellants' "means for deleting a 
specified snapshot copy of the production file from the version set" of claim 29 is shown in 
appellants' FIG. 26, steps 241, 242, 243, 244, as described in appellants' specification on page 
51 line 6 to page 53 line 20. The appellants' "means for restoring the production file with a 
specified snapshot copy of the production file" of claim 29 is shown in appellants' FIG. 29, FIG. 
30, steps 271-272, and FIG. 32, step 291; as described in appellants' specification on page 56 
line 4 to page 57 line 20 and page 58 lines 1-10. The appellants' "means for refreshing a 
specified snapshot copy of the production file" of claim 29 is shown in appellants' FIG. 33, steps 
301-304, as described in appellants' specification on page 58 lines 11 to 22. Appellants' "means 
for naming the files in the version set" of claim 29 is shown in appellants' FIGS. 34-35, steps 
311 to 324, as described in appellants' specification on page 59 line 1 to page 61 line 21. 

The appellants' independent claim 30 also is directed to a file server (21 in FIG. 1). The 
file server includes storage (29 in FIG. 1) containing a file system (54 in FIG. 2), and a processor 
(26 in FIG. 1) for accessing the file system. The file system includes a production file, and read- 
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only snapshot copies of the production file. The production file and the snapshot copies of the 
production file are organized as a version set. The version set includes an inode (171 in FIG. 19) 
for the production file and an inode (172-176 in FIG. 19) for each snapshot copy of the 
production file, and a set of file blocks (177 in FIG. 19) including data blocks and indirect blocks 
that are shared among the production file and the snapshot copies of the production file, as 
described in the specification as set out above for claim 29. In a similar fashion, appellants' 
claim 42 defines a method of operating such a file server. 

The appellants' claims 30 and 42 further deal with a problem that arises because file 
blocks including data blocks and indirect blocks are shared among a production file and read- 
only snapshot copies of the production file. This problem is whether or not to keep blocks of a 
read-only snapshot copy when the read-only snapshot copy is deleted. This problem is solved by 
programming the file server or operating the file server to maintain for each block in each 
snapshot copy of the production file an indication of whether or not said each snapshot copy of 
the production file is an oldest snapshot copy of the production file including an identical version 
of each block. (See spec, pg. 62 lines 13-21.) 

As further set out in appellant's claims 30 and 42, when deleting the read-only snapshot 
copy of the production file, the file server keeps each block for which the read-only snapshot 
copy is not indicated as being an oldest snapshot copy of the production file including an 
identical version of said each block. For example, as shown in appellants' FIG. 22, the 
indication is a non-owner flag 196, 197 associated with each data block pointer 194 or indirect 
block pointer 195 in the modified inode 190. (Appellants' specification, page 44 line 17 to page 
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45 line 14.) As shown in FIG. 26, step 243, for the first entry in the action table, if the block in 
the version being deleted is not owned by that version, then that block is ignored so it is not 
deleted. (Appellants' specification, page 52, lines 12-16.) 

Appellants' dependent claims 31 and 43 further define that each inode (e.g., 140 in FIG. 
15) of each read-only snapshot copy of the production file is linked to a hierarchy of blocks (e.g. 
132-139 in FIG. 15) included in said each read-only snapshot copy of the production file, and the 
deleting of the read-only snapshot copy of the production file includes keeping all descendants of 
said each block for which the read-only snapshot copy is not indicated as being an oldest 
snapshot copy of the production file including an identical version of said each block. Also with 
respect to Appellants' FIG. 26, step 243, for the first entry in the action table, by inheritance, all 
of the descendants of the block in the block hierarchy are shared with and owned by an earlier 
snapshot copy, so they also are ignored so they are not deleted. (See appellants' specification, 
page 52, lines 16-19.) 

Appellants' dependent claims 32 and 44 further define that the deleting of the read-only 
snapshot copy of the production file includes keeping each block for which the read-only 
snapshot copy of the production file is indicated as being an oldest snapshot copy of the 
production file including an identical version of said each block and a next-most recent snapshot 
copy of the production file is indicated as not being an oldest snapshot copy of the production 
file including an identical version of said each block. This is shown in appellants' FIG. 26, step 
243, in the second entry in the action table, as described in appellants' specification, page 52 line 
20 to page 53 line 5. 
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Appellants' dependent claims 33 and 45 further define, upon deleting the read-only 
snapshot copy of the production file, indicating that the next-most recent snapshot copy of the 
production file has become an oldest snapshot copy of the production file including an identical 
version of said each block for which the read-only snapshot copy of the production file is 
indicated as being an oldest snapshot copy of the production file including an identical version of 
said each block and a next-most recent snapshot copy of the production file is indicated as not 
being an oldest snapshot copy of the production file including an identical version of said each 
block. This is also shown in appellants' FIG. 26, step 243, in the second entry in the action table 
("Pass block to next"), as described in appellants' specification, page 52 line 20 to page 53 line 
5. 

Appellants' dependent claims 34 and 46 further define that the deleting of the read-only 
snapshot copy of the production file includes deallocating each block for which the read-only 
snapshot copy of the production file is indicated as being an oldest snapshot copy of the 
production file including an identical version of said each block and a next most recent snapshot 
copy of the production file is also indicated as being an oldest snapshot copy of the production 
file including an identical version of a block corresponding to said each block, wherein said each 
block and the block corresponding to said each block are mapped to the same logical file 
addresses. This is also shown in appellants' FIG. 26, step 243, in the third entry in the action 
table, as described in appellants' specification, page 53 lines 11-18. 

Appellants' claim 40 also is directed to a file server (21 in FIG. 1). The file server 
includes storage (29 in FIG. 1) containing a file system (54 in FIG. 2), and a processor (26 in 
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FIG. 1) for accessing the file system. The file system includes a production file, and read-only 
snapshot copies of the production file. The production file and the snapshot copies of the 
production file are organized as a version set. The version set includes an inode (171 in FIG. 19) 
for the production file and an inode (172-176 in FIG. 19) for each snapshot copy of the 
production file, and a set of file blocks (177 in FIG. 19) including data blocks and indirect blocks 
that are shared among the production file and the snapshot copies of the production file, as 
described in the specification as set out above for claim 29. In a similar fashion, appellants' 
claim 52 defines a method of operating such a file server. 

The appellants' claims 40 and 52 further call for refreshing a specified snapshot copy of 
the production file. The refreshing of appellants' claims 40 and 52 includes four distinct 
operations; namely, "creating a new inode in the version set, copying contents of the inode of 
the specified snapshot copy into the new inode so that the new inode references blocks of the 
specified snapshot copy, using the inode of the specified snapshot copy to create a new snapshot 
copy of the production file by copying contents of the inode of the production file into the inode 
of the specified snapshot copy, and performing a file deletion upon the new inode." This is 
shown in appellants' FIG. 33, steps 301 to 304, as described in appellants' specification, page 58 
lines 11-22. 

Appellants' dependent claims 41 and 53 further define that the file deletion upon the new 
inode is performed asynchronously after using the inode of the specified snapshot copy to create a 
new snapshot copy of the production file by copying contents of the inode of the production file into 
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the specified snapshot copy. This is shown in appellants' FIG. 33, steps 303-304, as described in 
appellants' specification, page 58, lines 16-22. 

Attached hereto as APPENDIX XI is a mapping of the elements of the claims on appeal 
to appellants' drawing figures by reference number and appellants' specification by page and 
line numbers. 



12 



Serial No.: 10/668,546 
Appeal Brief 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Whether claims 29-34, 40-46, 52, and 53 are unpatentable under 35 U.S.C. 
103(a) over U.S. Patent No. 6,434,681 issued to Armangau in view of U.S. patent No. 6,892,211 
issued to Hitz et al. 
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VII. ARGUMENT 

Claims 29-34, 40-46, 52, and 53 are patentable under 35 U.S.C. 103(a) over U.S. 
Patent No. 6,434,681 issued to Armangau (hereinafter Armangau ) in view of U.S. patent 
No. 6,892,211 issued to Hitz et al. (hereinafter Hitz). 

The policy of the Patent and Trademark Office has been to follow in each and every case the 
standard of patentability enunciated by the Supreme Court in Graham v. John Deere Co. , 148 
U.S.P.Q. 459 (1966). M.P.E.P. § 2141. As stated by the Supreme Court: 



Under § 103, the scope and content of the prior art are to be determined; 
differences between the prior art and the claims at issue are to be ascertained; and 
the level of ordinary skill in the pertinent art resolved. Against this background, 
the obviousness or nonobviousness of the subject matter is determined. Such 
secondary considerations as commercial success, long felt but unsolved needs, 
failure of others, etc., might be utilized to give light to the circumstances 
surrounding the origin of the subject matter sought to be patented. As indicia of 
obviousness or nonobviousness, these inquiries may have relevancy. 

148 U.S.P.Q. at 467. 

The problem that the inventor is trying to solve must be considered in determining whether 
or not the invention would have been obvious. The invention as a whole embraces the structure, 
properties and problems it solves. In re Wright . 848 F.2d 1216, 1219, 6 U.S.P.Q.2d 1959, 1961 
(Fed. Cir. 1988). 



Scope and content of the prior art 
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Armangau 

Armangau discloses a snapshot copy facility for a data storage system. A snapshot copy 
of a production data set is maintained while a host may continue write access to the production 
data set. The data storage system responds to a host request to write to a data storage location of 
the production data set by checking whether or not the storage location has been modified since 
the time when the snapshot was created, and upon finding that the storage location of the 
production data set has not been modified, copying data from the storage location of the 
production data set to an allocated storage location of the snapshot copy, and after copying data 
from the storage location of the production data set to the allocated storage location of the 
snapshot copy, performing the write operation upon the storage location of the production data 
set. In the preferred implementation, the data storage system allocates to the snapshot copy a bit 
map to indicate storage locations in the production data set that have been modified, and a list of 
pointers to allocated storage locations for the snapshot copy. The snapshot copy facility is useful 
so that a host write operation upon a storage location being backed up need not be delayed until 
original data in the storage location is written to secondary storage. ( Armangau , Abstract.) 

Armangau also discloses backup software (24 in Armangau FIG. 1), which a user or an 
application program can invoke to cause the host to issue a backup command. The backup 
software 24, for example, translates requests to backup logical data structures such as files, to 
backup commands that operate upon units of data storage specified in the backup commands 
transmitted by the host 20 to the primary data storage subsystem 21. For example, the units of 
data storage specified in the backup commands may include data storage volumes or devices, 
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cylinders, and tracks. (Armangau, col. 6, lines 19-29.) With reference to Armangau FIG. 1, in 
response to a backup command from the host 20, the primary data storage subsystem 21 accesses 
a primary directory 26 to find data of the physical storage unit specified by the backup command 
in order to initiate a process of copying the data from the primary storage 27 to the secondary 
storage 29 of the secondary data storage subsystem 22. Preferably, the primary directory 26 is 
constructed in such a way that the host can continue to access the primary storage 27 
concurrently with the copying process. For example, in response to the backup command from 
the host 20, the primary data storage subsystem creates an "instant snapshot copy" of the 
specified physical storage unit, and this instant snapshot copy is protected from modification by 
the host 20 while the instant snapshot copy is being written to the secondary storage 29. 
( Armangau . col. 6, lines 42-56.) Copying of the instant snapshot copy from the primary data 
storage system to the secondary storage system is performed by a remote link adapter as shown 
in FIG. 8A or FIG. 8C. (See Armangau . col. 16 line 13 to col. 67 and col. 17 line 53 to col. 18 
line 17.) 

In response to the user 23 or in response to a call from an application program executed 
by the host 20, the backup software 24 may issue a restore command to the primary data storage 
subsystem 21, and the restore command contains a tag of the backup version to be restored. The 
primary data storage subsystem forwards the restore command to the secondary data storage 
subsystem 22. In response to the restore command, the secondary data storage subsystem 
accesses the secondary directory 28 to find the secondary storage locations containing the 
version of backup data identified by the tag, and then copies the version of backup data from the 
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secondary storage 29 to the primary storage 27. Therefore, the version of the backup data 
identified by the tag becomes the current version in the primary storage 27. (Armangau, col. 8, 
lines 3-49.) 

Hitz 

Hitz discloses a method for keeping a file system in a consistent state and for creating 
read-only copies of a file system. Changes to the file system are tightly controlled. The file 
system progresses from one self-consistent state to another self-consistent state. The set of self- 
consistent blocks on disk that is rooted by the root inode is referred to as a consistency point. To 
implement consistency points, new data is written to unallocated blocks on disk. A new 
consistency point occurs when the fsinfo block is updated by writing a new root inode for the 
inode file into it. Thus, as long as the root inode is not updated, the state of the file system 
represented on disk does not change. The present invention also creates snapshots that are read- 
only copies of the file system. A snapshot uses no disk space when it is initially created. It is 
designed so that many different snapshots can be created for the same file system. Unlike prior 
art file systems that create a clone by duplicating the entire inode file and all of the indirect 
blocks, the present invention duplicates only the inode that describes the inode file. A multi-bit 
free-block map file is used to prevent data from being overwritten on disk. ( Hitz , Abstract.) 
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Differences between the prior art and the claims at issue 
Claim 29 

The appellants' invention of claim 29 is directed to a file server that maintains a file 
system including a production file, read-only snapshot copies of the production file, and at least 
one read-write snapshot copy of the production file. The production file and the snapshot copies 
of the production file are organized as a version set. The version set includes an inode for the 
production file and an inode for each snapshot copy of the production file, and a set of file blocks 
including data blocks and indirect blocks that are shared among the production file and the 
snapshot copies of the production file. 

Armangau does not disclose sharing of data blocks and indirect blocks among a 
production file and snapshot copies of the production file in a file system. Instead, the snapshot 
copy facility of Armangau creates and backs up a snapshot copy of a specified extent of a 
production volume, and may restore the extent of the production volume with the snapshot copy. 
As shown in FIG. 7B of Armangau , when writing to a track in an extent of a snapshot, if the 
track has not been modified, the "before image" of the track is copied from the production 
volume to a snapshot volume track (step 126) before writing new data to the track in the 
production volume (step 129). As shown in FIG. 8 A or 8C of Armangau , unmodified tracks of 
the production volume extent are copied from the production volume to secondary storage (step 
133 or 245), and the before images of the modified tracks are copied from the snapshot volume 
to the secondary storage (step 137 or 244). FIG. 9 of Armangau shows a format of a data record 
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on the backup tape. This data record includes, after an inter-record gap, a synchronization code 
142, a record number 143, a version ID 144, a track no. 145, track data 146, and finally an error 
correction code 147 preceding another inter-record gap 148. The records on the backup tape are 
not necessarily sequential by track number. (Armangau, col. 18, lines 18-25.) 

When data blocks and indirect blocks are shared among a production file and snapshot 
copies of the production file in a file system, the snapshot copies become read-only unless, as 
taught by appellants, a means is provided for unsharing blocks of a snapshot copy when writing 
data to the snapshot copy. For example, the snapshot copy facility of Hitz shares data blocks and 
indirect blocks between the production file and a newly created snapshot copy of the production 
file when the inode of the production file is duplicated. Hitz recognize that this "creates 
snapshots that are read-only copies of the file system." ( Hitz , Abstract; emphasis added; see also 
Hitz FIG. 18B and col. 18 lines 41-65; col. 23 lines 57-59.) However, Hitz fails to disclose or 
suggest making such snapshot file copies have a read-write capability in the file system. 

The appellants' claim 29 is a "means plus function" claim. Pursuant to 35 U.S.C. 112 
paragraph 6, "such claim shall be construed to cover the corresponding structure, material, or 
acts described in the specification and equivalents thereof." In re Donaldson 16 F.3d 1189, 1194, 
29 U.S.P.Q. 2d 1845, 1850 (Fed. Cir. 1994)(the PTO may not disregard the structure disclosed in 
the specification corresponding to a "means or step plus function" limitation in accordance with 35 
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U.S.C. § 112, 6th paragraph); see also In re Bond . 910 F.2d 831, 833, 1568, 15 U.S.P.Q.2d 1566 
(Fed. Cir. 1990). 

As set out above in the Summary of the Invention, corresponding structure, material, or 
acts for the "means plus function" in appellants' claim 29 are shown in appellants' FIGS. 24, 
FIG. 25, FIG. 26, FIG. 30, FIG. 32, FIG. 33, FIG. 34, and FIG. 35. 

Armangau 6,434,681 does not disclose the various operations performed by appellants' 
claimed means upon inodes because Armangau does not disclose sharing of data blocks and 
indirect blocks among a production file and snapshot copies of the production file in a file 
system. Nor does Armangau disclose that the restore includes a prepare restore operation and a 
commit restore operation. Nor does Armangau disclose a means for naming files in a version 
set. 

The appellants' means defined in claim 29 also have a structure and operation 
substantially different from Hitz because Hitz does not perform operations upon a read-write 
snapshot file in the file system. In particular, the appellants' means provide a mechanism for 
read-write snapshots to share data blocks and indirect blocks among a production file and 
snapshot copies by linking branch inodes upon base inodes that are inodes of read-only snapshot 
copies in a version chain. Thus, Hitz does not disclose or suggest the appellants' means of FIG. 
25 for creating a read-write branch snapshot inode off a read-only base snapshot inode, nor a 
restoration mechanism including a prepare restore involving the creation of a new branch file 
copy from a specified base version or a commit restore in which the new branch file assumes the 
identity of the production file, nor a means for naming the files in the version set including a way 
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of distinguishing read-write branch snapshots from read-only version snapshots and in particular 
identifying the read-only version upon which a branch snapshot is based. 

Where the prior art references fail to teach a claim limitation, there must be "concrete 
evidence" in the record to support an obviousness rejection. In re Zurko , 258 F.3d 1379, 1385- 
86, 59U.S.P.Q.2d 1693, 1697 (Fed. Cir. 2001). 

Claims 30 and 42 

As set out in appellants' independent claims 30 and 42, when deleting the read-only 
snapshot copy of the production file, the file server keeps each block for which the read-only 
snapshot copy is not indicated as being an oldest snapshot copy of the production file including 
an identical version of said each block. For example, as shown in appellants' FIG. 22, the 
indication is a non-owner flag 196, 197 associated with each data block pointer 194 or indirect 
block pointer 195 in the modified inode 190. (Appellants' specification, page 44 line 17 to page 
45 line 14.) As shown in FIG. 26, step 243, for the first entry in the action table, if the block in 
the version being deleted is not owned by that version, then that block is ignored so it is not 
deleted. (Appellants' specification, page 52, lines 12-16.) 

With respect to claims 30 and 42, the final Official Action (page 6) recognizes that 
Armangau does not explicitly disclose a set of file blocks including data blocks and indirect 
blocks that are shared among the production file and the read-only snapshot copies of the 
production file, or an oldest snapshot copy, or when deleting a read-only snapshot copy of the 
production file, keeping each block for which the read-only snapshot copy is not indicated as 
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being an oldest snapshot copy. For these features, the final Official Action (page 6) cites Hitz 
col. 6, lines 25-26; col. 21, lines 49-50; col. 23, lines 28-55. 

However, Hitz does not "maintain for each block in each snapshot copy of the 
production file an indication of whether or not said each snapshot copy of the production file is 
an oldest snapshot copy of the production file including an identical version of said each block" 
so that when deleting the read-only snapshot copy of the production file, the file server keeps 
each block for which the read-only snapshot copy is not indicated as being an oldest snapshot 
copy of the production file including an identical version of said each block. Instead, for re- 
allocation of blocks of a deleted snapshot, Hitz maintains a multi-bit free block map. A first bit 
in the multi-bit free block map indicates whether a block is used by the active file system, and 20 
remaining bits are used for up to 20 snapshots. ( Hitz col. 4, lines 38-48.) All snapshot bits are 
initially set to zero. If the active file bit is cleared before any snapshot bits are set, the block is 
not present in any snapshot stored on disk. Therefore, the block is immediately available for 
reallocation and cannot be recovered subsequently from a snapshot. ( Hitz col. 22, lines 1-6.) 
When a new snapshot is created, the entries in the block map are updated by copying the FS-bit 
into the snapshot bit. ( Hitz , FIG. 7, step 760, and FIG. 17D.) A snapshot is removed from the 
file system by clearing its snapshot inode entry in the inode file of the active file system and 
clearing each bit corresponding to the snapshot in every entry in the blkmap file. ( Hitz , col. 21, 
lines 50-54.) A disadvantage to this technique is the large number of bits involved. Thus, Hitz 
limits the total number of snapshots. ( Hitz , col. 18 lines 1 1-12; col. 21, line 61.) 
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Where the prior art references fail to teach a claim limitation, there must be "concrete 
evidence" in the record to support an obviousness rejection. In re Zurko , 258 F.3d 1379, 1385- 
86, 59U.S.P.Q.2d 1693, 1697 (Fed. Cir. 2001). 

Claims 31 and 43 

Appellants' dependent claims 3 1 and 43 further define that the deleting of the read-only 
snapshot copy of the production file includes keeping all descendants of said each block for 
which the read-only snapshot copy is not indicated as being an oldest snapshot copy of the 
production file including an identical version of said each block. Also with respect to 
Appellants' FIG. 26, step 243, for the first entry in the action table, by inheritance, all of the 
descendants of the block in the block hierarchy are shared with and owned by an earlier snapshot 
copy, so they also are ignored so they are not deleted. (See appellants' specification, page 52, 
lines 16-19, and page 45, lines 17-23.) 

The final Official Action (page 7) cites Armangau col. 7, Ins 35-47; col. 20, Ins. 55-67 
and Hitz col. 15, Ins. 30-41; col. 18, Ins. 34-40; col, 21, Ins. 49-50; col. 23, Ins. 28-55. It is not 
understood how the disclosure in these passages of Armangau and Hitz could be combined to 
result in the limitations of appellants' claims 31 and 43. Instead, Hitz clearly teaches that a 
different mechanism, namely a multi-bit free block map, is maintained for re-allocation of blocks 
from deleted snapshots. A first bit in the multi-bit free block map indicates whether a block is 
used by the active file system, and 20 remaining bits are used for up to 20 snapshots. A 
disadvantage to this technique is the large number of bits involved, so Hitz limits the total 
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number of snapshots. (Hitz, col. 18 lines 11-12; col. 21, line 61.) Thus, the appellants' 
invention of claims 3 1 and 43 offers a substantial advantage over Hitz because it is not necessary 
to maintain a respective bit for each possible combination of block and snapshot so that blocks 
no longer used by any version can be reallocated. 

Claims 32 and 44 

Appellants' dependent claims 32 and 44 further define that the deleting of the read-only 
snapshot copy of the production file includes keeping each block for which the read-only 
snapshot copy of the production file is indicated as being an oldest snapshot copy of the 
production file including an identical version of said each block and a next-most recent snapshot 
copy of the production file is indicated as not being an oldest snapshot copy of the production 
file including an identical version of said each block. This is shown in appellants' FIG. 26, step 
243, in the second entry in the action table, as described in appellants' specification, page 52 line 
20 to page 53 line 5. This logic is entirely absent from Armangau and Hitz . 

Claims 33 and 45 

Appellants' dependent claims 33 and 45 further define, upon deleting the read-only 
snapshot copy of the production file, indicating that the next-most recent snapshot copy of the 
production file has become an oldest snapshot copy of the production file including an identical 
version of said each block for which the read-only snapshot copy of the production file is 
indicated as being an oldest snapshot copy of the production file including an identical version of 
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said each block and a next-most recent snapshot copy of the production file is indicated as not 
being an oldest snapshot copy of the production file including an identical version of said each 
block. This is also shown in appellants' FIG. 26, step 243, in the second entry in the action table 
("Pass block to next"), as described in appellants' specification, page 52 line 20 to page 53 line 
5. This logic is entirely absent from Armangau and Hitz . 

Claims 34 and 46 

Appellants' dependent claims 34 and 46 further define that the deleting of the read-only 
snapshot copy of the production file includes deallocating each block for which the read-only 
snapshot copy of the production file is indicated as being an oldest snapshot copy of the 
production file including an identical version of said each block and a next most recent snapshot 
copy of the production file is also indicated as being an oldest snapshot copy of the production 
file including an identical version of a block corresponding to said each block, wherein said each 
block and the block corresponding to said each block are mapped to the same logical file 
addresses. This is also shown in appellants' FIG. 26, step 243, in the third entry in the action 
table, as described in appellants' specification, page 53 lines 11-18. This logic is entirely absent 
from Armangau and Hitz . 

Claims 40 and 52 

The appellants' independent claims 40 and 52 call for refreshing a specified snapshot 
copy of the production file. In general, refreshing of a specified snapshot copy is different from 
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restoring the production file with a snapshot copy. (For example, compare the appellants' restore 
of FIGS. 29, 30, and 32 to appellants' refresh of FIG. 33.) In particular, the refreshing of 
appellants' claims 40 and 52 includes four distinct operations; namely, "creating a new inode in 
the version set, copying contents of the inode of the specified snapshot copy into the new inode 
so that the new inode references blocks of the specified snapshot copy, using the inode of the 
specified snapshot copy to create a new snapshot copy of the production file by copying contents 
of the inode of the production file into the inode of the specified snapshot copy, and performing a 
file deletion upon the new inode." This is shown in appellants' FIG. 33, steps 301 to 304, as 
described in appellants' specification, page 58 lines 1 1-22. 

The final Official Action (pages 9-10) suggests that the four distinct operations in the 
claimed refreshing result by combining Hitz's teaching of keeping a consistent file using an 
inode for each snapshot with Armangau's teaching of a snapshot copy maintenance system. 
However, the appellants' four-step refreshing does not result by using the snapshot copy facility 
of Armangau to copy a volume extent containing a file having an inode. Instead, Armangau (e.g. 
col. 8 lines 47-49) describes copying a version of backup data identified by a tag from the 
secondary storage 39 to the primary storage 29 so that the version of the backup data identified 
by the tag becomes the current version in the primary storage. Thus, whatever was in the volume 
extent at the time of the snapshot will be put back as it was in primary storage. Therefore, it is 
not understood how the appellants' four distinct operations for a refresh are suggested by the 
restoration technique of Armangau in view of the teaching in Hitz of up to twenty snapshot copy 
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inodes that may share data blocks and direct blocks with an active file system (Hitz col. 3, lines 
13-30 and col. 18, lines 1-18). 

"[Rejections on obviousness grounds cannot be sustained by mere conclusory 
statements; instead, there must be some articulated reasoning with some rational underpinning to 
support the legal conclusion of obviousness." In re Kahn , 441 F. 3d 977, 988 (Fed. Cir. 2006). 
A fact finder should be aware of the distortion caused by hindsight bias and must be cautious of 

arguments reliant upon ex post reasoning. See KSR International Co. v. Teleflex Inc ., 550 U.S. , 

82 USPQ2d 1385 (2007)). citing Graham . 383 U. S. at 36 (warning against a "temptation to read 
into the prior art the teachings of the invention in issue" and instructing courts to "guard against 
slipping into the use of hindsight"). 

Claims 41 and 53 

Appellants' dependent claims 41 and 53 further define that the file deletion upon the new 
inode is performed asynchronously after using the inode of the specified snapshot copy to create a 
new snapshot copy of the production file by copying contents of the inode of the production file into 
the specified snapshot copy. The final Official Action (page 10) cites Armangau col. 20, lines 55- 
67 and Hitz col. 18, lines 1-16. Armangau col. 20 lines 55-57 relates to a procedure of FIG. 16 
invoked when a data mover receives a backup request from a primary data storage subsystem. Hitz 
col. 18 lines 1-16 relates to the WAFL system supporting up to 20 different snapshots each 
represented by a snapshot inode. It is not understood how these passages disclose or suggest the 
limitations of appellants' claims 41 and 53, which specify that file deletion upon the new inode is 



27 



Serial No.: 10/668,546 
Appeal Brief 



performed asynchronously after using the inode of the specified snapshot copy to create a new 
snapshot copy of the production file. 

In view of the above, the rejections of the claims should be reversed. 



Respectfully submitted, 

Richard C. Auchterlonie 
Reg. No. 30,607 

NOVAK DRUCE & QUIGG, LLP 
1000 Louisiana, 53 rd Floor 
Houston, TX 77002 
713-571-3400 



28 



Serial No.: 10/668,546 
Appeal Brief 



VIII. CLAIMS APPENDIX 

The claims involved in this appeal are as follows: 

29. A file server comprising: 

storage containing a file system; and 

a processor coupled to the storage for accessing the file system; 

wherein the file system includes a production file, read-only snapshot copies of the 
production file, and at least one read-write snapshot copy of the production file; 

wherein the production file and the snapshot copies of the production file are organized 
as a version set; the version set including an inode for the production file and an inode for each 
snapshot copy of the production file, and a set of file blocks including data blocks and indirect 
blocks that are shared among the production file and the snapshot copies of the production file; 
and 

wherein the file server further includes: 

means for creating new read-only snapshot copies of the production file; 

means for creating new read-write snapshot copies of the production file; 

means for deleting a specified snapshot copy of the production file from the version set; 

means for restoring the production file with a specified snapshot copy of the production 

file; 

means for refreshing a specified snapshot copy of the production file; and 
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means for naming the files in the version set. 

30. A file server comprising: 

storage containing a file system; and 

a processor coupled to the storage for accessing the file system; 

wherein the file system includes a production file, and read-only snapshot copies of the 
production file; 

wherein the production file and the read-only snapshot copies of the production file are 
organized as a version set; the version set including an inode for the production file, an inode for 
each read-only snapshot copy of the production file, and a set of file blocks including data blocks 
and indirect blocks that are shared among the production file and the read-only snapshot copies 
of the production file; 

wherein the file server is programmed to maintain for each block in each snapshot copy 
of the production file an indication of whether or not said each snapshot copy of the production 
file is an oldest snapshot copy of the production file including an identical version of said each 
block; and 

wherein the file server is programmed to delete a read-only snapshot copy of the 
production file, and when deleting the read-only snapshot copy of the production file, to keep 
each block for which the read-only snapshot copy is not indicated as being an oldest snapshot 
copy of the production file including an identical version of said each block. 
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31. The file server as claimed in claim 30, wherein each inode of each read-only snapshot 
copy of the production file is linked to a hierarchy of blocks included in said each read-only 
snapshot copy of the production file, and wherein the file server is further programmed, upon 
deleting the read-only snapshot copy of the production file, to keep all descendants of said each 
block for which the read-only snapshot copy is not indicated as being an oldest snapshot copy of 
the production file including an identical version of said each block. 

32. The file server as claimed in claim 30, which is further programmed, upon deleting the 
read-only snapshot copy of the production file, to keep each block for which the read-only 
snapshot is indicated as being an oldest snapshot copy of the production file including an 
identical version of said each block and a next-most recent snapshot copy of the production file 
is indicated as not being an oldest snapshot copy of the production file including an identical 
version of said each block. 

33. The file server as claimed in claim 32, which is further programmed, upon deleting the 
read-only snapshot copy of the production file, to indicate that the next-most recent snapshot 
copy of the production file has become an oldest snapshot copy of the production file including 
an identical version of said each block for which the read-only snapshot is indicated as being an 
oldest snapshot copy of the production file including an identical version of said each block and 
a next-most recent snapshot copy of the production file is indicated as not being an oldest 
snapshot copy of the production file including an identical version of said each block. 
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34. The file server as claimed in claim 30, which is further programmed, upon deleting the 
read-only snapshot copy of the production file, to deallocate each block for which the read-only 
snapshot copy is indicated as an oldest snapshot copy of the production file including an 
identical version of said each block and a next most recent snapshot copy of the production file is 
also indicated as an oldest snapshot copy of the production file including an identical version of a 
block corresponding to said each block, wherein said each block and the block corresponding to 
said each block are mapped to the same logical file addresses. 

40. A file server comprising: 

storage containing a file system; and 

a processor coupled to the storage for accessing the file system; 

wherein the file system includes a production file, and snapshot copies of the production 

file; 

wherein the production file and the snapshot copies of the production file are organized 
as a version set; the version set including an inode for the production file, an inode for each 
snapshot copy of the production file, and a set of file blocks including data blocks and indirect 
blocks that are shared among the production file and the snapshot copies of the production file; 
and 

wherein the file server is programmed for refreshing a specified snapshot copy of the 
production file by creating a new inode in the version set, copying contents of the inode of the 
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specified snapshot copy into the new inode so that the new inode references blocks of the 
specified snapshot copy, using the inode of the specified snapshot copy to create a new snapshot 
copy of the production file by copying contents of the inode of the production file into the inode 
of the specified snapshot copy, and performing a file deletion upon the new inode. 

41. The file server as claimed in claim 40, wherein the file deletion upon the new inode is 
performed asynchronously after using the inode of the specified snapshot copy to create a new 
snapshot copy of the production file by copying contents of the inode of the production file into 
the inode of the specified snapshot copy. 

42. A method of operating a file server; the file server including storage containing a file 
system, and the file server also including a processor coupled to the storage for accessing the file 
system; the file system including a production file and read-only snapshot copies of the 
production file; the production file and the read-only snapshot copies of the production file being 
organized as a version set; the version set including an inode for the production file, an inode for 
each read-only snapshot copy of the production file, and a set of file blocks including data blocks 
and indirect blocks that are shared among the production file and the read-only snapshot copies 
of the production file; said method comprising: 

maintaining for each block in each snapshot copy of the production file an indication of 
whether or not said each snapshot copy of the production file is an oldest snapshot copy of the 
production file including an identical version of said each block; and 
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deleting a read-only snapshot copy of the production file, wherein the deleting of the 
read-only snapshot copy of the production file includes keeping each block for which the read- 
only snapshot copy is not indicated as being an oldest snapshot copy of the production file 
including an identical version of said each block. 

43. The method as claimed in claim 42, wherein each inode of each read-only snapshot copy 
of the production file is linked to a hierarchy of blocks included in said each read-only snapshot 
copy of the production file, and wherein the deleting of the read-only snapshot copy of the 
production file includes keeping all descendants of said each block for which the read-only 
snapshot copy is not indicated as being an oldest snapshot copy of the production file including 
an identical version of said each block. 

44. The method as claimed in claim 42, wherein the deleting of the read-only snapshot copy 
of the production file further includes keeping each block for which the read-only snapshot copy 
of the production file is indicated as being an oldest snapshot copy of the production file 
including an identical version of said each block and a next-most recent snapshot copy of the 
production file is indicated as not being an oldest snapshot copy of the production file including 
an identical version of said each block. 

45. The method as claimed in claim 44, which further includes, upon deleting the read-only 
snapshot copy of the production file, indicating that the next-most recent snapshot copy of the 
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production file has become an oldest snapshot copy of the production file including an identical 
version of said each block for which the read-only snapshot copy of the production file is 
indicated as being an oldest snapshot copy of the production file including an identical version of 
said each block and a next-most recent snapshot copy of the production file is indicated as not 
being an oldest snapshot copy of the production file including an identical version of said each 
block. 

46. The method as claimed in claim 42, wherein the deleting of the read-only snapshot copy 
of the production file includes deallocating each block for which the read-only snapshot copy of 
the production file is indicated as being an oldest snapshot copy of the production file including 
an identical version of said each block and a next most recent snapshot copy of the production 
file is also indicated as being an oldest snapshot copy of the production file including an identical 
version of a block corresponding to said each block, wherein said each block and the block 
corresponding to said each block are mapped to the same logical file addresses. 

52. A method of operating a file server; the file server including storage containing a file 
system, and the file server also including a processor coupled to the storage for accessing the file 
system; the file system including a production file and snapshot copies of the production file; the 
production file and the snapshot copies of the production file being organized as a version set; 
the version set including an inode for the production file, an inode for each snapshot copy of the 
production file, and a set of file blocks including data blocks and indirect blocks that are shared 
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among the production file and the snapshot copies of the production file; said method 
comprising: 

the file server refreshing a specified snapshot copy of the production file by creating a 
new inode in the version set, copying contents of the inode of the specified snapshot copy into 
the new inode so that the new inode references blocks of the specified snapshot copy, using the 
inode of the specified snapshot copy to create a new snapshot copy of the production file by 
copying contents of the inode of the production file into the inode of the specified snapshot copy, 
and performing a file deletion upon the new inode. 

53. The method as claimed in claim 52, which includes the file server performing the 
file deletion upon the new inode asynchronously after using the inode of the specified read-only 
snapshot copy to create the new snapshot copy of the production file by copying contents of the 
inode of the production file into the inode of the specified snapshot copy 
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IX. EVIDENCE APPENDIX 

None. 
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X. RELATED PROCEEDINGS APPENDIX 

None. 
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XL MAP OF CLAIM ELEMENTS TO DRAWINGS AND SPECIFICATION 

29. A file server (21 in FIG. 1; spec pg. 3 line 21, pg. 12 lines 10-11) comprising: 

storage (29 in FIG. 1 and FIG. 2; spec pg. 3 lines 21-23, pg. 12 lines 11-13) containing a 
file system (54 in FIG. 2; pg. 3 lines 21-23, pg. 14 lines 3-5); and 

a processor (26 in FIG. 1 and FIG. 2; spec. pg. 3 line 23 -pg. 4 line 2, pg. 12 lines 11-13, 
pg. 14 lines 1-7) coupled to the storage for accessing the file system; 

wherein the file system includes a production file, read-only snapshot copies of the 
production file, and at least one read- write snapshot copy of the production file (FIG. 19; spec, 
pg. 4 lines 14-16, pg. 10 lines 19-20, pg. 41 line 20-pg. 42 line 10); 

wherein the production file and the snapshot copies of the production file are organized 
as a version set (FIG. 19; pg. 42 lines 3-10); the version set including an inode for the production 
file (171 in FIG. 19) and an inode for each snapshot copy of the production file (172-176 in FIG. 
19), and a set of file blocks (177 in FIG. 19) including data blocks (e.g., 132, 134, 135, 138, 139 
in FIG. 15; spec. pg. 32 lines 5-13) and indirect blocks (e.g. 133, 136, 137 in FIG. 15; spec. pg. 
32 lines 5-13) that are shared among the production file and the snapshot copies of the 
production file (spec. pg. 3 lines 2-6, pg. 42 lines 3-10); and 

wherein the file server further includes: 

means for creating new read-only snapshot copies of the production file (steps 221-227 in 
FIG. 24, spec, page 50 lines 3-15); 
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means for creating new read-write snapshot copies of the production file (steps 231-237 
in FIG. 25, spec. pg. 50 line 16 to pg 51 line 5); 

means for deleting a specified snapshot copy of the production file from the version set 
(steps 241-244 in FIG. 26; spec. pg. 51 line 6 to pg. 53 line 20); 

means for restoring the production file with a specified snapshot copy of the production 
file ( FIG. 29; steps 271-272 in FIG. 30; step 291 FIG. 32; spec. pg. 56 line 4 to pg. 57 line 20; 
pg. 58 lines 1-10); 

means for refreshing a specified snapshot copy of the production file appellants' (steps 
301-304 in FIG. 33; spec. pg. 58 lines 1 1 to 22); and 

means for naming the files in the version set (steps 31 1-317 in FIG. 34, steps 318-324 in 
FIG. 34; spec. pg. 59 line 1 to pg. 61 line 21). 

30. A file server (21 in FIG. 1; spec. pg. 4 line 1 1, pg. 12 lines 10-1 1) comprising: 

storage (29 in FIG. 1 and FIG. 2; spec pg. 4 lines 12-14, pg. 12 lines 11-13) containing a 

file system (54 in FIG. 2; pg. 14 lines 3-5); and 

a processor (26 in FIG. 1 and FIG. 2; spec. pg. 4 lines 12-14, pg. 12 lines 11-13, pg. 14 

lines 1-7) coupled to the storage for accessing the file system; 

wherein the file system includes a production file, and read-only snapshot copies of the 

production file (FIG. 19; spec. pg. 4 lines 14-15, pg. 10 lines 19-20, pg. 41 line 20-pg. 42 line 

10); 
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wherein the production file and the read-only snapshot copies of the production file are 
organized as a version set (FIG. 19; pg. 42 lines 3-10); the version set including an inode for the 
production file (171 in FIG. 19), an inode for each read-only snapshot copy of the production file 
(172-174 in FIG. 19), and a set of file blocks (177 in FIG. 19) including data blocks (e.g., 132, 
134, 135, 138, 139 in FIG. 15; spec. pg. 32 lines 5-13) and indirect blocks (e.g. 133, 136, 137 in 
FIG. 15; spec. pg. 32 lines 5-13) that are shared among the production file and the read-only 
snapshot copies of the production file (spec. pg. 4 lines 14-19, pg. 12 lines 3-10); 

wherein the file server is programmed (step 225 in FIG. 24, step 234 in FIG. 25, step 243 
in FIG. 26) to maintain for each block in each snapshot copy of the production file an indication 
(flags 196, 197 in FIG. 22; pg. 44 line 17 to pg. 45 line 2) of whether or not said each snapshot 
copy of the production file is an oldest snapshot copy of the production file including an identical 
version of said each block (spec. pg. 4 lines 19-22, pg. 32 lines 16-22); and 

wherein the file server is programmed to delete a read-only snapshot copy of the 
production file (steps 241-244 in FIG. 26; spec. pg. 4 lines 22-23, pg. 61 lines 6-11), and when 
deleting the read-only snapshot copy of the production file, to keep each block for which the 
read-only snapshot copy is not indicated as being an oldest snapshot copy of the production file 
including an identical version of said each block (step 243 ignore block case in FIG. 26; spec pg. 
4 line 22 - pg. 5 line 3, pg. 51 lines 12-16). 

31. The file server as claimed in claim 30, wherein each inode (e.g., 140 in FIG. 15) of each 
read-only snapshot copy of the production file is linked to a hierarchy of blocks (e.g. 132-139 in 
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FIG. 16) included in said each read-only snapshot copy of the production file, and wherein the 
file server is further programmed, upon deleting the read-only snapshot copy of the production 
file, to keep all descendants of said each block for which the read-only snapshot copy is not 
indicated as being an oldest snapshot copy of the production file including an identical version of 
said each block (step 243 ignore block case in FIG. 26; spec. pg. 52 lines 16-19). 

32. The file server as claimed in claim 30, which is further programmed, upon deleting the 
read-only snapshot copy of the production file, to keep each block for which the read-only 
snapshot is indicated as being an oldest snapshot copy of the production file including an 
identical version of said each block and a next-most recent snapshot copy of the production file 
is indicated as not being an oldest snapshot copy of the production file including an identical 
version of said each block (step 243 pass block to next case in FIG. 26; spec. pg. 52 line 20 to 
pg. 53 line 5). 

33. The file server as claimed in claim 32, which is further programmed, upon deleting the 
read-only snapshot copy of the production file, to indicate that the next-most recent snapshot 
copy of the production file has become an oldest snapshot copy of the production file including 
an identical version of said each block for which the read-only snapshot is indicated as being an 
oldest snapshot copy of the production file including an identical version of said each block and 
a next-most recent snapshot copy of the production file is indicated as not being an oldest 
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snapshot copy of the production file including an identical version of said each block (step 243 
pass block to next case in FIG. 26; spec. pg. 52 line 20 to pg. 53 line 5). 

34. The file server as claimed in claim 30, which is further programmed, upon deleting the 
read-only snapshot copy of the production file, to deallocate each block for which the read-only 
snapshot copy is indicated as an oldest snapshot copy of the production file including an 
identical version of said each block and a next most recent snapshot copy of the production file is 
also indicated as an oldest snapshot copy of the production file including an identical version of a 
block corresponding to said each block, wherein said each block and the block corresponding to 
said each block are mapped to the same logical file addresses (step 243 third entry in table in 
FIG. 26; spec. pg. 53 lines 11-18). 

40. A file server (21 in FIG. 1; spec pg. 6 line 4, pg. 12 lines 10-11) comprising: 

storage (29 in FIG. 1 and FIG. 2; spec pg. 6 lines 4-6, pg. 12 lines 11-13) containing a file 
system (54 in FIG. 2; spec. pg. 14 lines 3-5); and 

a processor (26 in FIG. 1 and FIG. 2; spec. pg. 6 lines 4-6, pg. 12 lines 11-13) coupled to 
the storage for accessing the file system; 

wherein the file system includes a production file, and snapshot copies of the production 
file (FIG. 19; spec. pg. 6 lines 6-7, pg. 10 lines 19-20, pg. 41 lines 20 to pg. 42 line 10); 

wherein the production file and the snapshot copies of the production file are organized 
as a version set (FIG. 19; spec. pg. 42 lines 3-10); the version set including an inode for the 
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production file (171 in FIG. 19), an inode for each snapshot copy of the production file (172-176 
in FIG. 19), and a set of file blocks (177 in FIG. 19) including data blocks (e.g., 132, 134, 135, 
138, 139 in FIG. 15; spec. pg. 32 lines 5-13) and indirect blocks (e.g. 133, 136, 137 in FIG. 15; 
spec. pg. 32 lines 5-13) that are shared among the production file and the snapshot copies of the 
production file (spec. pg. 6 lines 7-11, pg. 42 lines 3-10); and 

wherein the file server is programmed for refreshing a specified snapshot copy of the 
production file (FIG. 33; spec. pg. 11-17, pg. 58 lines 11-13) by creating a new inode in the 
version set (step 301 in FIG. 33; spec. pg. 58 lines 13-14), copying contents of the inode of the 
specified snapshot copy into the new inode so that the new inode references blocks of the 
specified snapshot copy (step 301 in FIG. 33 pg. 58 lines 14-15), using the inode of the specified 
snapshot copy to create a new snapshot copy of the production file by copying contents of the 
inode of the production file into the inode of the specified snapshot copy (step 303 in FIG. 33; 
spec. pg. 58 lines 16-19), and performing a file deletion upon the new inode (step 304 in FIG. 33; 
pg. 58 lines 19-21). 

41. The file server as claimed in claim 40, wherein the file deletion upon the new inode is 
performed asynchronously after using the inode of the specified snapshot copy to create a new 
snapshot copy of the production file by copying contents of the inode of the production file into 
the inode of the specified snapshot copy (step 304 after step 303 in FIG. 33; spec. pg. 58 lines 
16-22). 
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42. A method of operating a file server (21 in FIG. 1; spec. pg. 6 lines 18-19, pg. 12 lines 10- 
1 1); the file server including storage (29 in FIG. 1 and FIG. 2; spec pg. 6 line 19, pg. 12 lines 11- 
13) containing a file system (54 in FIG. 2; pg. 14 lines 3-5), and the file server also including a 
processor (26 in FIG. 1 and FIG. 2; spec. pg. 6 lines 19-20, pg. 12 lines 11-13, pg. 14 lines 1-7) 
coupled to the storage for accessing the file system; the file system including a production file 
and read-only snapshot copies of the production file (FIG. 19; spec. pg. 6 lines 20-21, pg. 10 
lines 19-20, pg. 41 line 20-pg. 42 line 10); the production file and the read-only snapshot copies 
of the production file being organized as a version set (FIG. 19; spec. pg. 6 lines 21-22, pg. 42 
lines 3-10); the version set including an inode for the production file (171 in FIG. 19), an inode 
for each read-only snapshot copy of the production file (172-174 in FIG. 19), and a set of file 
blocks (177 in FIG. 19) including data blocks (e.g., 132, 134, 135, 138, 139 in FIG. 15; spec. pg. 
32 lines 5-13) and indirect blocks (e.g. 133, 136, 137 in FIG. 15; spec. pg. 32 lines 5-13) that are 
shared among the production file and the read-only snapshot copies of the production file (spec, 
pg. 6 line 22 to pg. 7 line 2, pg. 12 lines 3-10); said method comprising: 

maintaining (step 225 in FIG. 24, step 234 in FIG. 25, step 243 in FIG. 26) for each block 
in each snapshot copy of the production file an indication (flags 196, 197 in FIG. 22; pg. 44 line 
17 to pg. 45 line 2) of whether or not said each snapshot copy of the production file is an oldest 
snapshot copy of the production file including an identical version of said each block (spec. pg. 6 
lines 2-5, pg. 32 lines 16-22); and 

deleting a read-only snapshot copy of the production file (steps 241-244 in FIG. 26; spec, 
pg. 4 lines 22-23, pg. 61 lines 6-11), wherein the deleting of the read-only snapshot copy of the 
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production file includes keeping each block for which the read-only snapshot copy is not 
indicated as being an oldest snapshot copy of the production file including an identical version of 
said each block (step 243 ignore block case in FIG. 26; spec pg. 6 lines 5-9, pg. 51 lines 12-16). 

43. The method as claimed in claim 42, wherein each inode (e.g., 140 in FIG. 15) of each 
read-only snapshot copy of the production file is linked to a hierarchy of blocks (e.g. 132-139 in 
FIG. 16) included in said each read-only snapshot copy of the production file, and wherein the 
deleting of the read-only snapshot copy of the production file includes keeping all descendants of 
said each block for which the read-only snapshot copy is not indicated as being an oldest 
snapshot copy of the production file including an identical version of said each block (step 243 
ignore block case in FIG. 26; spec. pg. 52 lines 16-19). 

44. The method as claimed in claim 42, wherein the deleting of the read-only snapshot copy 
of the production file further includes keeping each block for which the read-only snapshot copy 
of the production file is indicated as being an oldest snapshot copy of the production file 
including an identical version of said each block and a next-most recent snapshot copy of the 
production file is indicated as not being an oldest snapshot copy of the production file including 
an identical version of said each block (step 243 ignore block case in FIG. 26; spec. pg. 52 lines 
16-19). 
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45. The method as claimed in claim 44, which further includes, upon deleting the read-only 
snapshot copy of the production file, indicating that the next-most recent snapshot copy of the 
production file has become an oldest snapshot copy of the production file including an identical 
version of said each block for which the read-only snapshot copy of the production file is 
indicated as being an oldest snapshot copy of the production file including an identical version of 
said each block and a next-most recent snapshot copy of the production file is indicated as not 
being an oldest snapshot copy of the production file including an identical version of said each 
block (step 243 pass block to next case in FIG. 26; spec. pg. 52 line 20 to pg. 53 line 5). 

46. The method as claimed in claim 42, wherein the deleting of the read-only snapshot copy 
of the production file includes deallocating each block for which the read-only snapshot copy of 
the production file is indicated as being an oldest snapshot copy of the production file including 
an identical version of said each block and a next most recent snapshot copy of the production 
file is also indicated as being an oldest snapshot copy of the production file including an identical 
version of a block corresponding to said each block, wherein said each block and the block 
corresponding to said each block are mapped to the same logical file addresses (step 243 third 
entry in table in FIG. 26; spec. pg. 53 lines 11-18). 

52. A method of operating a file server (21 in FIG. 1; spec pg. 8 lines 12-13, pg. 12 lines 10- 
1 1); the file server including storage (29 in FIG. 1 and FIG. 2; spec pg. 8 lines 13-14, pg. 12 lines 
11-13) containing a file system (54 in FIG. 2; pg. 14 lines 3-5), and the file server also including 
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a processor (26 in FIG. 1 and FIG. 2; spec. pg. 8 lines 13-14, pg. 12 lines 11-13) coupled to the 
storage for accessing the file system; the file system including a production file and snapshot 
copies of the production file (FIG. 19; spec. pg. 8 lines 14-15, pg. 10 lines 19-20, pg. 41 lines 20 
to page 42 line 10); the production file and the snapshot copies of the production file being 
organized as a version set (FIG. 19; spec. pg. 42 lines 3-10); the version set including an inode 
for the production file (171 in FIG. 19), an inode for each snapshot copy of the production file 
(172-176 in FIG. 19), and a set of file blocks (177 in FIG. 19) including data blocks (e.g., 132, 
134, 135, 138, 139 in FIG. 15; spec. pg. 32 lines 5-13) and indirect blocks (e.g. 133, 136, 137 in 
FIG. 15; spec. pg. 32 lines 5-13) that are shared among the production file and the snapshot 
copies of the production file (spec. pg. 8 lines 15-19, pg. 42 lines 3-10); said method comprising: 
the file server refreshing a specified snapshot copy of the production file (FIG. 33; spec, 
pg. 8 line 19 to pg. 9 line 2, pg. 58 lines 1 1-13) by creating a new inode in the version set (step 
301 in FIG. 33; spec. pg. 58 lines 13-14), copying contents of the inode of the specified snapshot 
copy into the new inode so that the new inode references blocks of the specified snapshot copy 
(step 301 in FIG. 33; spec. pg. 58 lines 14-15), using the inode of the specified snapshot copy to 
create a new snapshot copy of the production file by copying contents of the inode of the 
production file into the inode of the specified snapshot copy using the inode of the specified 
snapshot copy to create a new snapshot copy of the production file by copying contents of the 
inode of the production file into the inode of the specified snapshot copy (step 303 in FIG. 33; 
spec. pg. 58 lines 16-19), and performing a file deletion upon the new inode (step 304 in FIG. 33; 
pg. 58 lines 19-21). 

48 



Serial No.: 10/668,546 
Appeal Brief 



53. The method as claimed in claim 52, which includes the file server performing the 
file deletion upon the new inode asynchronously after using the inode of the specified read-only 
snapshot copy to create the new snapshot copy of the production file by copying contents of the 
inode of the production file into the inode of the specified snapshot copy (step 304 after step 303 
in FIG. 33; spec. pg. 58 lines 16-22). 
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